home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000108_news@watsun.cc.columbia.edu _Thu May 27 19:23:03 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
2KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id TAA21005
for <kermit.misc@watsun.cc.columbia.edu>; Thu, 27 May 1999 19:23:03 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id TAA19388
for kermit.misc@watsun.cc.columbia.edu; Thu, 27 May 1999 19:02:09 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: kermit process hangs around after terminal disconnect
Message-ID: <LZ2MDEdX4Nvq@cc.usu.edu>
Date: 27 May 99 16:55:55 MDT
Organization: Utah State University
To: kermit.misc@watsun.cc.columbia.edu
In article <7ik1om$1o9$1@nnrp1.deja.com>, Mr. Scott <scott_davis@my-deja.com> writes:
> Thank you for the explanation.
> I learned something new today, and, after all, that's what the
> newsgroups are for!
> I vote for a new transport layer protocol that uses keep alive packets.
> But then again, I see why this wasn't done in the first place:
> network traffic.
> The perils of living in an imperfect world with imperfect solutions...
----------
Yes, what you say is true deeper down too. Those folks who use
telco lines with charging would appreciate not having hello pkts dialing
up, those with ISDN lines wouldn't notice too much until the bill arrives,
and those with lan connections would shrug and say bandwidth is someone
else's problem. Alas, simply turning off/crashing the client takes awhile
to notice even with probes (as a safety margin for flakey nets). And
eventually we will be dinged by the packet if the commercial operators can
manage it.
In the meanwhile, Unix systems can implement overall timers to kick
off inactive machines (even though network comms are fine, or otherwise).
So please speak with your Unix system manager and above about this common
feature. Keep in mind that other users may complain about lost work overnight
when their jobs have no interaction for many hours.
And the TCP/IP protocol stacks can be constructed to implement
TCP (not UDP) keepalive probes. Same folks to talk with.
Joe D.